Data stored on a computer system is typically arranged into one or more data storage spaces. Collectively, these data storage spaces are often referred to as a database. Each data storage space comprises one or more data items. Data items in a particular space share common characteristics. A data item may have a value for each of these characteristics. For example, relational databases store data in a number of spaces known as tables. The data items in each table, forming the “rows” of the table, share the same “columns” of data, in that for each column of data, any item in the table may have a value.
It is helpful to partition data storage spaces for administrative purposes such as archiving, caching, enhancing performance, copying or deleting data, and free space management. For example, spaces that store data items with date characteristics are often partitioned so that each partition comprises only those items that pertain to a particular range of dates. One partition, for example, might only store data items pertaining to a particular month. Another partition might only store data items that pertain to a particular fiscal quarter. Since a partition also comprises data items that share common characteristics, a partition may also be considered a data storage space.
The determination of to which, if any, partition a data item pertains is made by looking up one or more of the data item's values in a partition mapping. The partition mapping maps certain sets or ranges of values to certain partitions. These sets or ranges of values correspond to one or more characteristics shared by the data items in the partitioned storage space. These characteristics are known as partitioning characteristics. For tables, these sets or ranges of values may correspond to the value of a particular column upon which the partition mapping is said to be based. This column is known as the partitioning column. For example, a partition mapping for a table might be based upon the value of a data item's date column. The mapping could define ranges of dates, such as months or years. Each range could pertain to a separate partition. To determine the partition to which a new data item pertains, one would determine under which of the defined ranges the value of the item's date column fell. Partition mappings may be based on multiple partitioning columns, which is often the case with subpartitions. Partition mappings may also be based on a variety of other characteristics, such as whether a data item pertains to a particular range of numbers or set of discrete values.
When a new data storage space (or partition) is created, a database system typically performs a number of tasks. One of these tasks is to allocate a segment for the space. A segment is the region within a system's memory or filesystem wherein data for a storage space is stored. The segment may be located via a corresponding segment address. The size of the segment may be defined during the creation process, or may be determined by the database system based on factors such as characteristics of the data storage space and database configuration parameters.
Another task typically performed when a space is created is to create metadata describing the new space, which is subsequently maintained by the database system. Database systems typically maintain metadata describing each data storage space and partition. Such metadata may describe, for instance, a data space's name, segment address, and segment size. The metadata may also indicate information that helps interpret the data stored within the segment, such as information about the characteristics of the data items within the data storage space. For example, it may define the size, name, and type of each column of data found within a table. It may also describe a partition's name and mapping scheme. It may also describe performance or functionality enhancing ancillary objects such as indexes. Many database systems maintain this metadata in one or more system storage spaces.
Applications that make use of databases often create a large number of permanent data storage spaces when they are installed or initiated. Often, this is done according to a schema describing each space and partition that the application may use during the course of its operation. By creating spaces up front, applications avoid making costly determinations at later stages concerning the existence of a particular space. However, some or even most of these spaces may not be used for a very long time, if at all. Since segments and metadata must be created for each of them, memory or filesystem resources that could have been used for other purposes are potentially permanently tied up with empty segments and unused metadata. Furthermore, to the extent that certain spaces remain permanently unused, the time spent creating metadata and allocating segments for them also represents undesirable waste.
Currently, the only way to circumvent this problem is for application developers or database administrators to create storage spaces only when they are necessary. Unfortunately, this workaround requires high overhead. Application developers may end up writing potentially large amounts of code to make sure that the required spaces are created at the proper place and time. Database administrators may end up having to become unnecessarily familiar with the structure of their databases, and may furthermore have to devote large amounts of time to anticipating or tracking the needs of applications that use their databases.
It is therefore highly desirable to provide a less overhead-intensive mechanism to overcome the problem of resource-wasting inherent to up-front data storage space creation strategies.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.